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Whit  is  in  this  PrimenP 

The  Software  Reuse  Executive  Primer 
provides  a  simple  and  understandable 
overview  of  software  reuse. 

This  Primer  presents  the  issues  and  benefits  involved 
in  transitioning  to  reuse-based  software  acquisition,  de¬ 
velopment,  and  maintenance  processes,  and  answers 
frequently  asked  questions  about  software  reuse.  Tech¬ 
nical  and  organizational  issues  are  discussed  along  with 
successful  reuse  management  techniques. 

•  No  prior  knowledge  of  software  reuse  by  the 
reader  is  assumed. 

•  Acronyms  are  listed  in  Appendix  A.  The  Bibli¬ 
ography  in  Appendix  B  lists  references  and  other 
software  reuse  publications.  Software  reuse 
points  of  contact  (POC)  are  listed  in 
Appendix  C. 

•  Occasional  mention  of  commercial  companies 
and  product  names  in  the  course  of  providing 
examples,  is  not  to  be  considered  an  endorse¬ 
ment  of  these  companies  or  products  by  the 
Department  of  Defense  (DOD)  Software  Re¬ 
use  Initiative  (SRI)  Program  Management  Of¬ 
fice  (PMO). 

•  This  Primer  is  not  intended  to  replace  authorita¬ 
tive  plans,  policies,  or  directives.  DOD  soft¬ 
ware  reuse  plans,  policies  and  directives  are 
found  in  formal  documents  published  by  the 
Office  of  the  Secretary  of  Defense  (OSD),  the 
SRI  PMO,  the  Services,  and  DOD  Agencies. 

Why  Do  You  Want  to  Read  This  PrimiiP 

Because  DOD  acquisition  managers  are 
responsible  for  implementing  software 
reuse. 


The  Software  Reuse  Executive  Primer  was  writ¬ 
ten  to  answer  the  following  seventeen  que.stions  posed 
by  DOD  acquisition  managers  relative  to  software 
reuse  in  simple  language; 


•  Why  haven’t  we  taken  advantage  of  software  re¬ 
use  before? 

•  What  do  I  reuse? 

•  What  are  the  benefits  of  reuse? 

•  What  are  the  barriers  to  reuse? 

•  What  are  the  key  non-technical  issues? 

•  What  are  the  key  technical  issues? 

•  What  is  the  DOD's  strategy  for  reuse? 

•  How  do  I  know  if  I  am  ready  for  reuse? 

•  Where  do  I  get  help  to  kick  off  a  reuse  program? 

•  What  are  the  upfront  investments? 

•  What  are  common  mistakes  and  how  do  I  avoid 
them? 

•  How  do  I  measure  my  return  on  investment? 

•  What  are  my  next  steps? 

•  Where  do  I  go  for  more  information? 

This  Primer  is  aimed  at  whetting  the  appetite  of 
those  acquisition  managers  responsible  for  imple¬ 
menting  software  reuse  within  both  the  weapons  sys¬ 
tems  and  information  systems  communities  of  the 
DOD.  Managers  should  be  interested  in  reuse  be¬ 
cause  they  are  looking  for  ways  to  reduce  cost,  ac¬ 
celerate  schedules,  and  improve  software  quality. 
Program  Managers.  Program  Executive  Officers,  and 
Direct  Reporting  Program  Managers  fall  into  this 
category  as  does  anyone  else  who  may  benefit  by 
implementing  a  reuse  program. 

What  is  Softwabe  RebseP 

Software  reuse  is  defined  as  the  process 
of  implementing  or  updating  software 
systems  using  existing  software 
assets.  [NIST] 


Software  reuse  is  the  application  of  reusable  soft¬ 
ware  assets  to  more  than  one  software  system.  Soft¬ 
ware  reuse  may  occur  within  a  software  system, 
across  similar  software  systems,  or  in  widely  differ¬ 
ent  software  systems.  [NIST] 

A  reusable  software  asset  is  a  software  product 
that  is  cataloged  in  a  reuse  library.  [NIST]  This  in¬ 
cludes,  for  example,  models  of  distinct  functional 
areas  (i.e.,  domains),  domain  architectures,  architec¬ 
tures,  requirements,  designs,  code,  databases,  data¬ 
base  schemas,  documentation,  user  manuals,  and  test 


•  What  is  software  reuse? 

•  Why  is  software  reuse  important? 

•  Where  has  it  paid  off? 


suites. 


ously  developed  software  and  by  developing  software 
designed  for  future  reuse. 


Why  is  Softwme  Rebse  ImpbihuitP 

•  Software  reuse  provides  a  basis  for 
dramatic  improvements  in  quality 
and  reliability,  speed  of  delivery,  and 
in  long-term  decreased  costs  for  soft¬ 
ware  development  and  maintenance. 

•  Industry  and  DOD  have  demon¬ 
strated  that  software  reuse  generates 
significant  return  on  investment  by 
reducing  cost,  time,  and  effort  while 
increasing  quality,  productivity,  and 
maintainability  of  software  systems 
throughout  the  software  life-cycle. 


The  Department  of  Defense  and  the  Congress 
have  stressed  the  importance  of  reducing  the  cost, 
time,  and  effort  required  to  build  and  maintain  soft¬ 
ware  systems  for  the  DOD.  This  applies  to  both  in- 
house  and  contractor-developed  systems.  Software 
reuse  has  been  demonstrated  by  Industry  and  the 
DOD  to  provide  one  of  the  greatest  returns  on  in¬ 
vestment  (ROI)  for  reducing  cost,  time,  and  effort 
while  increasing  quality,  productivity,  and  maintain¬ 
ability  throughout  the  software  life-cycle. 


When  software  acquisition,  development,  and 
maintenance  organizations  develop  reusable 
software  products,  they  will  do  more 
“shopping  for  the  best  fit”  when  preparing 
to  work  on  future  software  projects. 

DOD  software  development  costs  have  out¬ 
stripped  hardware  costs  and  are  continuing  to  grow. 
The  major  factors  contributing  to  this  growth  of  soft¬ 
ware  costs  are  the  continuing  increase  in  the  size  and 
complexity  of  software  systems  and  an  international 
climate  that  calls  for  rapid  adaptation  to  new  situa¬ 
tions.  Software  reuse  offers  significant  potential  to 
hold  down  future  costs  by  taking  advantage  of  previ¬ 


A  significant  challenge  to  both  DOD  manage¬ 
ment  and  technical  staff  is  to  improve  the  quality  and 
reliability  of  an  organization's  systems  in  an  era  of 
decreasing  budgets.  The  challenge  is  intensified  by 
the  ever  increasing  complexity  and  functionality  of 
modem  information  systems.  One  response  to  this 
situation  that  has  proven  successful  is  the  integration 
of  software  reuse  principles  into  the  software  engi¬ 
neering  process. 

Software  reuse  provides  a  basis  for  dramatic  im¬ 
provement  in  the  way  software  systems  are  devel¬ 
oped  and  maintained  over  their  life-cycle.  Reusable 
software  requires  carefully  analyzed  and  structured 
design  that  withstands  thorough  testing  for  function¬ 
ality,  reliability,  and  modularity.  Accordingly,  im¬ 
provements  manifest  themselves  in  increased  qual¬ 
ity  and  reliability  and  in  long-term  decreased  costs 
for  software  development  and  maintenance. 


Reuse  reduces  the  risks  and  costs  of  software 
acquisition,  development,  and  maintenance. 

Other  benefits  of  adopting  reuse  include  improved 
interoperability  and  support  for  rapid  prototyping 
activities.  A  well  mn  reuse  program  decreases  ini¬ 
tial  risk  for  development,  maintenance,  and  acquisi¬ 
tion  activities  by  taking  advantage  of  software  already 
proven  to  be  functional  and  reliable  through  prior 
usage. 

Reuse  is  already  an  integral  part  of  every  engi¬ 
neering  discipline.  For  example,  mechanical  engi¬ 
neers  do  not  design  a  combustion  engine  from  scratch 
for  each  car  rolled  off  an  assembly  line;  software  en¬ 
gineers  do  not  recreate  the  interaction  between  an 
application  and  its  screen  icon  for  each  new  product; 


and  aerospace  engineers  do  not  build  solid  rocket 
boosters  from  ground  zero  for  each  space  shuttle.  In 
all  of  these  examples,  the  architecture  and  design  of 
an  item  is  reused  to  produce  and  manage  a  “product 
line.” 

Reusable  software  also  can  be  acquired,  devel¬ 
oped,  maintained,  and  managed  via  a  “product-line” 
approach.  For  example,  during  this  era  of  rightsizing 
we  have  to  build  systems  quickly  and  cheaply.  One 
strategy  for  doing  this  is  to  move  to  product-line  tech¬ 
niques  like  commercial  firms  use  to  achieve  econo¬ 
mies  of  scale. 

The  product-line  approach  will  increase  the  soft¬ 
ware  acquisition,  development,  and  maintenance 
community’s  responsiveness  to  DOD’s  plans  and 
requirements  for  the  future.  The  anticipated  result  is 
a  DOD  capability  to  deliver  more  responsive,  higher 
quality  products  (systems)  to  the  end  user  more 
quickly,  at  reduced  cost,  and  with  less  risk  because 
common  software  is  reused. 


A  product-line  approach  similar  to  that  of 
automobile  manufacturing  can  be  adapted  to 
software  acquisition,  development,  and 
maintenance  processes. 


Whebe  Has  It  Paib  Off? 

Industry  has  realized  many  instances  of 
significant  payoff  by  instituting  software 
reuse  practices. 

Hewlett  Packard,  since  instituting  software  re¬ 
use  in  the  mid-1980s,  has  experienced  quantifiable 
benefits  such  as: 


•  Quality  -  Defects  for  reused  code  were  only  one- 
fourth  the  defects  for  new  code.  [IEEE] 

•  Productivity'  -  Developing  systems  with  new  and 
reused  code  yielded  a  577c  increase  in  produc¬ 
tivity  over  developing  systems  with  only  new 
code.  [IEEE] 

•  Time-to-Market  -  With  equivalent  development 
effort,  using  reusable  software  assets  required 
42%  less  time  to  deliver  the  final  product. 

Computer  Science  Corporation  developed  the 
Upper  Atmosphere  Research  Satellite  (UARS)  te¬ 
lemetry  simulator  using  a  design  that  allowed  for  fu¬ 
ture  reuse.  The  UARS  reusable  assets  have  subse¬ 
quently  been  reused  in  three  other  projects: 

•  The  Extreme  Ultra  Violet  Explorer  (EUVE)  te¬ 
lemetry  simulator  reused  89%  of  UARS  code 
without  modifications.  Labor  hours  were  re¬ 
duced  67%  while  productivity  was  three  times 
that  on  the  original  UARS  development  project. 
An  order  of  magnitude  improvement  in  software 
quality  was  achieved  with  a  final  error  rate  less 
than  one-tenth  the  original  UARS  telemetry 
simulator  project’s  error  rate. 

•  In  the  Solar,  Anomalous,  and  Magnetospheric 
Particle  Explorer  (SAMPEX),  85%  of  the 
UARS  telemetry  simulator  architecture  was  re¬ 
used.  Staff  hours  on  the  project  were  307c  less 
than  EUVE’s,  and  the  error  rate  was  reduced 
similarly. 

•  The  WIND/POLAR  telemetry  simulator  used 
55%  of  the  reusable  UARS  telemetry  simulator 
architecture.  Schedule,  effort,  productivity,  and 
quality  estimates  were  improved  like  those  of 
EUVE  and  SAMPEX. 

TRW  Inc.’s  National  Universal  Network  Archi¬ 
tecture  Services  project  had  an  estimated  $6  million 
upfront  investment  in  performance  optimization,  de¬ 
sign  for  reuse,  and  portability.  Using  a  second  gen¬ 
eration  product,  TRW  saw  a  two-fold  increase  in  pro¬ 
ductivity  over  typical  software  developments,  due  to 
a  decrease  in  the  volume  of  software  errors  found  in 
initial  test  configurations  and  a  reduction  in  the  aver¬ 
age  time  required  to  correct  errors. 
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Why  Haven’t  We  Taken  AovANnei  of 
SOFTWAIE  ReDSE  BeFOIeP 

Reusing  software  to  reduce  cost,  speed 
development,  and  increase  quality  is  not 
a  new  concept. 

Software  reuse  has  existed  conceptually  and  prac¬ 
tically  in  a  variety  of  forms  and  methodologies  since 
the  early  years  of  software  development.  Early  soft¬ 
ware  reuse  practices  were  focused  on  reusing  source 
code  only.  This  often  proved  cumbersome  and  inef¬ 
ficient  as  storage  and  access  technology  was  limited. 
Now,  technology  has  progressed  to  the  point  where 
virtually  all  categories  of  software  assets  can  be  stored 
and  accessed  efficiently,  thus  making  software  reuse 
a  viable  software  engineering  discipline. 

Software  reuse  doesn’t  just  happen.  Both  man¬ 
agement  and  technical  issues  must  be  tackled  to  tran¬ 
sition  successfully  to  a  reuse-based  culture.  Once 
these  issues  are  managed,  the  benefits  discussed 
above  can  be  garnered. 

What  Do  I  RedseP 

Any  product  from  the  software  life-cycle 
can  potentially  be  reused. 

Reusable  assets  include,  for  example,  domain 
models,  domain  architectures,  requirements,  design, 
code,  databases,  database  schemas,  documentation, 
user  manuals,  and  test  suites.  Reusable  software 
assets  typically  are  cataloged  and  stored  in  a  reuse 
library.  The  catalog  entries  include  identification  and 
descriptive  data  that  helps  the  user  to  determine  an 
asset’s  suitability  for  reuse.  [V&S]  By  developing 
software  systems  with  reuse  in  mind,  one  can  take 
advantage  of  standards-based  architecture  method¬ 
ologies  that  will  support  reuse  of  entire  designs  and 
whole  subsystems. 

What  Are  the  Benefits  of  ReoseP 

F  Lower  cost  systems. 


Software  reuse  will  yield  significant  benefits  to 
the  software  acquisition,  development,  and  mainte¬ 


nance  communities.  Commercial  firms  and  govern¬ 
ment  organizations  have  demonstrated  that  software 

reuse  will: 

•  Improve  the  quality  and  reliability  of  software- 
intensive  systems; 

•  Provide  earlier  identification  and  improved  man¬ 
agement  of  software  technical  risk; 

•  Shorten  system  development  and  maintenance 
time; 

•  Get  products  to  market  sooner; 

•  Increase  productivity ;  and 

•  Reduce  cost. 

What  are  the  Barriers  to  RebseP 

•  Non-technical  and  technical  barriers 
to  software  reuse  exist. 

•  The  SRI  PMO  is  working  to  remove 
these  barriers  to  reach  the  SRI  objec¬ 
tive  of  institutionalizing  software  re¬ 
use  within  DOD. 


Non-technical  Barriers 

Non-technical  barriers  to  reuse  involve  manage¬ 
ment  issues,  reuse  standards,  acquisition  issues,  train¬ 
ing  and  education  issues,  and  library  reuse  issues. 
These  non-technical  barriers  continue  to  cause  the 
greatest  delay  in  DOD-wide  acceptance  and  utiliza¬ 
tion  of  proven,  documented  software  reuse  concepts 
and  methodologies.  [STRAT] 

The  SRI  PMO  is  overcoming  non-technical  bar¬ 
riers  by  providing  a  Software  Reuse  Business  Model 
(SRBM),  recently  developed  by  the  U.S.  Army  Space 
and  Strategic  Defense  Command,  that  can  be  tailored 
to  a  variety  of  scenarios  and  sets  of  business  prac¬ 
tices.  [STRAT] 

To  assi.st  the  acquisition  process,  the  SRI  PMO 
has  sponsored  the  development  of  software  reuse 
business  models  and  will  publish  a  Program 
Manager’s  Reuse  Issues  Handbook.  The  SRI  PMO 
also  encourages  using  incentives  to  accept  risks  as¬ 
sociated  with  incorporating  software  reuse  concepts 
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and  procedures  throughout  the  software  development 
life-cycle.  [STRAT] 

Technical  Barriers 

Technical  barriers  to  reuse  involve  technical  pro¬ 
cesses,  methods,  tools,  standards,  and  technology- 
based  environments  for  software  systems  acquisition, 
development,  and  maintenance.  Software  reuse  is 
not  a  stand-alone  technology  —  it  must  be  pervasive 
throughout  the  life-cycle.  [STRAT] 

The  SRI  PMO  is  overcoming  technical  barriers 
by  developing  a  reuse-based  software  systems  engi¬ 
neering  paradigm  and  expediting  the  rapid  transfer 
of  reuse  technology.  This  involves  identifying  best 
practices  in  Government  and  Industry;  providing  an 
integrated  software  engineering  environment  includ¬ 
ing  the  tools  to  support  domain  engineering  and  re¬ 
use;  and  providing  a  clearly  defined  technology 
roadmap  that  identifies  critical  technology  to  support 
software  reuse.  [STRAT] 

What  Are  the  Key  Nor-Technical  IssoesP 

• . . . 

•  A  reuse-focused  culture  is  required. 

•  Reuse  management  and  infrastructure.  Al¬ 
though  software  reuse  technology  is  constantly 
improving,  we  have  to  put  in  place  management 
structures  to  absorb,  channel,  and  take  advan¬ 
tage  of  it.  [AMPROG] 

•  Committing  inadequate  resources  for  reuse. 
Reuse  doesn’t  just  happen.  Resources  must  be 
allocated  to  acquire,  build,  maintain,  manage, 
and  upgrade  domain  knowledge,  architectures, 
and  support  tools. 

•  Assuming  any  reuse  is  good  reuse.  Directives 
to  reuse  any  software  available  compete  with, 
and  eventually  can  defeat,  engineering  and  busi¬ 
ness  objectives.  Reuse  should  be  well  planned, 
systematic,  reliable,  and  should  add  value  to  the 
project.  Reuse  goals  should  be  established  that 
support  achieving  business  and  engineering  ob¬ 
jectives. 

•  Using  project-by-project  opportun  istic  ad  hoc 
reuse  only.  Project-by-project  opportunistic  ad 
hoc  reuse,  although  a  legitimate  short-term  tac¬ 


tic,  will  not  provide  the  long-term  benefits  of  a 
systematic  software  reuse  program.  To  reap 
maximum  benefits,  reuse  must  be  systematic 
and  considered  across  related  systems  (vertical 
domain)  and  across  common  features  of  possi¬ 
bly  unrelated  systems  (horizontal  domain).  A 
hybrid  domain  (with  some  vertical  and  some 
horizontal  aspects)  promises  the  greatest  re¬ 
wards  for  systematic  reuse. 

•  Populating  architectures  and  repositories. 
Architectures  represent  candidate  solutions  for 
whole  families  of  related  systems  within  a  do¬ 
main.  Populating  these  architectures  entails  de¬ 
sign  decisions  that  reflect  the  architecture.  Popu¬ 
lating  repositories  with  high-quality  reusable 
software  as  it  is  developed  is  an  integral  part  of 
a  long-term  investment  strategy  and  is  critical 
to  realizing  high  economic  and  technical  payoff 
in  future  software  efforts. 

•  Parochial  attitudes.  Software  engineers  still 
tend  to  mistrust  assets  produced  by  someone 
else.  They  need  to  be  continuously  motivated 
to  reuse  assets,  not  redevelop  them.  To  address 
this  issue,  certification  schemes  have  been  de¬ 
veloped  and  used  by  several  organizations. 
[AMPROG] 


Change  attitude  from  “not  invented  here” 
to  “we  reuse  here”. 

Not  rewarding  developers  for  reusing  software 
when  developing  with  reusable  assets,  and 
when  developing  {^future  reuse.  Contract 
award  fees  and  productivity  metrics  should  be 
established  to  encourage  software  engineers  to 
develop  software  systems  with  reusable  soft¬ 
ware,  and  to  design  components  of  new  soft- 
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ware  systems  for  future  reusability.  When  de¬ 
veloping  for  future  reuse,  a  good  rule  of  thumb 
is  that  reusable  products  will  take  twice  the  de¬ 
velopment  effort  as  that  required  for  develop¬ 
ing  non-reusable  products.  Hence,  reusable 
products  are  initially  more  expensive,  but  result 
in  downstream  cost  avoidance  for  related  soft¬ 
ware  components  in  the  product  line.  Software 
reusability  should  be  aimed  at  enterprise  pro¬ 
ductivity  across  a  product  line  of  systems  or 
families  of  related  systems,  rather  than  at  indi¬ 
vidual  or  project-level  productivity. 

Using  short-sighted  metrics.  Contract  award 
fees  are  commonly  based  on  the  amount  of  soft¬ 
ware  reused.  A  more  appropriate  award  fee 
would  be  based  on  the  percentage  of  final  deliv¬ 
ered  software  that  is  composed  oi reusable  soft¬ 
ware.  This  latter  metric  encourages  contractors 
to  populate  and  maintain  architectures  and  re¬ 
positories  in  support  of  future  reuse  efforts. 

What  abe  the  Key  Techhigal  Issoes? 

Associated  with  architectures: 

•  Standards  for  representation. 

•  Tools  to  assist  modification  and  in¬ 
tegration  of  multiple  structural 
views;  and  automated  change  mecha¬ 
nisms. 

Associated  with  reusing  software  assets 

of  all  types  (architectures,  designs,  docu¬ 
mentation,  code,  etc.): 

•  Asset  production  and  configuration 
management. 

•  Asset  locators. 

•  Asset  control. 


Issues  Associated  with  Architectures 

The  wide-spread  use  of  architectures  to  guide 
software  development  is  relatively  new.  Therefore, 
automated  tools  to  assist  in  their  development,  main¬ 
tenance,  and  modification  are  not  commonly  avail¬ 
able.  However,  research  in  the  field  of  enterprise 
integration  may  yield  advances  in  techniques  to  inte¬ 
grate  models  representing  varying  structural  views. 


changes  throughout  the  life-cycle  product  line  (e.g., 
architectures,  domain  models,  data  models,  design 
documentation),  and  while  they  will  not  be  available 
for  some  time,  they  will  allow  organizations  attempt¬ 
ing  to  develop  and  maintain  architectures  to  have 
access  to  some  technological  support. 

The  SRI  PMO  supports  the  concept  of  develop¬ 
ing  system  architectures  that  will  provide  a  frame¬ 
work  for  the  design  of  reusable  software.  Plans  call 
for  identification  and  acquisition  within  two  years  of 
“best  of  breed"  architectures  for  the  initial,  high-le¬ 
verage  product  lines.  After  five  years,  the  objective 
is  to  have  at  least  one  complete,  validated  architec¬ 
ture  for  each  active  product  line.  [STRAT] 

Issues  Associated  with  Reusing  Software  Assets  of 
All  Types 

System  development  and  maintenance  organiza¬ 
tions  have  similar  technical  challenges;  finding,  un¬ 
derstanding.  modifying,  integrating,  and  composing 
assets;  developing,  populating,  maintaining,  and 
managing  architectures;  and  creating  and  managing 
software  components  such  as  designs  and  documen¬ 
tation. 

Automated  tools  should  be  selected  to  provide 
the  greatest  capabilities  in  location,  selection,  u.se,  and 
control  of  the  assets.  Promising  technologies  should 
be  identified  and  tools  procured  that  give  the  most 
functionality.  These  tools  speed  development  and  help 
bring  about  a  complete  asset  inventory  with  standard¬ 
ized  style  and  structure.  This  facilitates  maintain¬ 
ability  and,  most  of  all,  use  of  the  assets. 

Organizations  need  to  develop  and  maintain  con¬ 
figuration  management  information  (e.g.,  an  auto¬ 
mated  index  of  all  architectures  and  other  compo¬ 
nents).  Brief,  precise,  and  functional  descriptions 
should  be  included.  This  will  assist  in  reusing  these 
assets  and  will  identify  opportunities  for  future  re¬ 
use. 

The  SRI  PMO  has  established  the  Defense  Soft¬ 
ware  Repository  System  (DSRS)  for  use  by  all  DOD 
components.  This  repository  will  provide  on-line 
support  to  organizations  desiring  to  use  proven  and 
reliable  software  assets. 


More  than  likely,  tools  will  precede  standards  and 
organizations  responsible  for  maintaining  domain 
knowledge.  Such  tools  will  automatically  ripple 


What  is  the  DOD’s  Strategy  for  ReuseP 

•  The  DOD  SRI  has  established  an 
incremental  strategy  for  institution¬ 
alizing  software  reuse  within  the 
DOD. 

•  The  DOD  SRI  will  use  a  five-pronged 
approach  to  implement  the  strategy. 

The  DOD  SRI’s  incremental  strategy  for  adopt¬ 
ing  software  reuse  will  produce  initial  successes 
within  two  years.  By  the  end  of  five  years,  the  strat¬ 
egy  is  expected  to  provide  the  foundation  to  achieve 
widespread  acceptance  of  software  reuse  as  an  inte¬ 
gral  component  of  software  systems  acquisition,  de¬ 
velopment,  and  maintenance.  The  SRI  will  use  the 
five-pronged  approach  illustrated  in  the  accompany¬ 
ing  figure.  The  five  thrusts  are  based  upon  lessons 
learned  to  date,  including  current  plans  and  programs, 
user  requirements,  and  Congressional  guidance.  An 
overview  of  each  thrust  follows:  [STRAT] 

•  Implement  a  Product-Line  Approach  will  re¬ 
construct  the  way  DOD  organizations  acquire, 
develop,  and  maintain  software  systems.  A 
product  line  is  a  set  of  software  systems  with 
common  architectures  that  satisfy  the  mission 
requirements  of  one  or  more  domains.  A  prod¬ 
uct-line  approach  involves  developing  and  ap¬ 


plying  reusable  assets  among  software  systems 
possessing  similar  architectures.  [STRAT] 

Develop  a  Reuse-Based  Software  Systems 
Engineering  Paradigm  will  build  and  maintain 
a  technical  foundation  for  reuse-based  software 
systems  engineering.  This  will  be  accomplished 
by  identifying  the  best  practices  and  supporting 
environments  for  conducting  software  reuse. 
This  thrust  will  institutionalize  reuse  concepts 
by  making  reuse  an  integral  part  of  software 
systems  engineering.  [STRAT] 

Remove  Barriers  to  Reuse  will  identify  and 
remove  non-technical  barriers  such  as  legal, 
contractual,  organizational,  and  economic,  that 
inhibit  the  product-line  approach  to  software 
acquisition,  development,  and  maintenance. 
Incentives  to  speed  reuse  adoption  also  will  be 
provided.  [STRAT] 

Quicken  Technology  Transfer  will  develop 
processes,  products,  service  solutions,  and  ap¬ 
propriate  partnerships  for  expediting  the  adop¬ 
tion  and  institutionalization  of  software  reuse. 
Quick  technology  transfer  also  will  be  stimu¬ 
lated  through  a  variety  of  partnerships  among 
the  DOD,  other  Government  organizations.  In¬ 
dustry,  and  Academia.  [STRAT] 
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Five-Pronged  Approach  to  Institutionalize  Software  Reuse  within  DOD 


•  Make  Successes  Apparent  will  publicize  soft¬ 
ware  reuse  successes  and  provide  sufficient  in¬ 
formation  to  promote  reuse  awareness  within 
the  DOD.  Widespread  dissemination  of  reuse 
information  will  be  provided  to  further  the  un¬ 
derstanding  of  reuse  and  its  benefits.  [STRAT] 

How  Do  I  Know  if  I  am  Reaoy  foe  Reuse? 

•  Select  projects  within  a  distinct  do¬ 
main  (functional  area)  to  minimize 
risk. 

•  Domain- specific  reuse  allows  for  an 
iterative,  incremental  adoption  of  re¬ 
use.  This  evolutionary  method  has 
less  risk  associated  with  it  than  a 
revolutionary,  “big  hang”  method. 

You  are  ready  for  reuse  when  the  associated  risks 
are  at  an  acceptable  level.  Analysis  of  the  domain  in 
which  you  are  operating  is  the  key  to  determining 
that  level. 

Selecting  projects  within  a  single  domain  leads 
to  achieving  systematic  reuse.  Limiting  the  focus  of 
the  software  engineering  effort  to  a  single  well  de¬ 
fined  and  well  understood  set  of  functions,  increases 
the  opportunities  for  successful  software  reuse.  Thus, 
reusable  software  assets  can  be  identified  precisely 
and  utilized  efficiently.  The  narrowness  of  the  do¬ 
main  reduces  the  investment  in  the  reuse  repository 
because  the  domain  is  well  understood,  the  problem 
is  well  understood,  and  engineers  can  “get  their  minds 
around  it”.  If  a  domain  is  too  large  to  be  managed, 
then  it  should  be  sectioned  into  subdomains. 

The  type  of  domain  also  is  important.  A  low- 
risk  domain  for  reuse  is  one  in  which  the  technology 
and  the  products  are  relatively  stable  or  evolving  at  a 
manageable  pace.  A  high-risk  domain  for  reuse  is 
one  in  which  the  underlying  technology  is  rapidly 
changing  (e.g.,  system  software  for  personal  com¬ 
puters  and  workstations). 

Selecting  a  single  domain  project  allows  an  or¬ 
ganization  to  refine  its  reuse  techniques.  Experience 
is  developed  within  a  single  domain.  Metrics  can  be 
uniform  throughout  the  domain's  projects  and  are 
easily  compared.  Examples  of  using  metrics  are: 


•  For  a  software  acquisition  organization,  the  pro¬ 
posal  and  vendor  evaluation  criteria  will  have 
been  tested  and  recalibrated,  and  their  useful¬ 
ness  and  veracity  will  have  been  demonstrated 
repeatedly. 

•  For  a  software  development  organization,  as 
more  softw'are  assets  are  made  available  for  re¬ 
use  in  the  repository',  software  development  costs 
will  begin  to  decrease. 

•  For  a  softw'are  maintenance  organization,  de¬ 
sign  rationales  and  implementation  decisions  for 
the  systems  within  the  domain  can  be  evaluated 
and  compared  in  order  to  justify  accepting  or 
rejecting  modification  requests. 

Wheie  Do  I  Get  Help  to  Kick 
_ Off  a  Reose  Pbosbam? _ 

•  Call  your  Service  ! Agency  software 
reuse  POC. 

•  Coordinate  your  software  reuse 
projects  among  different  functional 
areas  (i.e.,  domains). 

•  Participate  in  your  Service  ! Agency 

_ reuse  planning. _ 

Get  help  by  calling  your  Service/ Agency  software 
reuse  POC.  They  are  listed  in  Appendix  C  and  are 
available  to  discuss  starting  a  reuse  program. 

It  is  important  to  coordinate  your  software  reuse 
projects  among  different  functional  areas.  This  en¬ 
ables  different  program  managers  to  take  advantage 
of  ongoing  reuse  development  efforts.  The  Services’/ 
Agencies’  reuse  plans  will  establish  an  initial  frame¬ 
work  from  which  all  reuse  efforts  within  the  Service/ 
Agency  will  be  coordinated.  Priorities  will  be  de¬ 
fined  and  will  influence  budgets.  Accordingly,  it  is 
essential  for  acquisition  managers  to  participate  in 
this  planning  process. 


What  aie  the  Upfraht  IhwestmehtsP 

I  Successful  software  reuse  requires  an 

upfront  investment. 

Opportunities  to  implement  software  reuse  must 
be  seized  as  early  as  possible.  The  specifics  of  the 
upfront  investment  opportunity  vary  among  acquisi¬ 
tion.  development,  and  maintenance  managers. 

For  acquisition  organizations,  the  upfront  invest¬ 
ment  will  be  in  redesigning  the  current  evaluation 
system  for  proposals  and  vendors  so  that  bidders  will 
be  rewarded  for  applying  reuse.  Criteria  should  be 
included  in  the  solicitation  that  will:  ( 1 )  forecast  the 
percentage  of  reusability  expected  for  a  project;  and 
(2)  accurately  capture  the  breadth  and  depth  of  the 
bidder’s  experience  with  reuse.  During  the  proposal 
evaluation  phase,  acquisition  organizations  should 
ensure  that  the  bidder’s  software  reuse  plan  is  ex¬ 
ecutable  and  capable  of  providing  desired  levels  of 
software  reuse  performance.  Some  organizations 
have  already  pioneered  these  changes  so  your  upfront 
investment  can  be  reduced  by  copying  or  adapting 
from  these  efforts. 

For  development  and  maintenance  organizations, 
the  additional  upfront  investment  will  be  the  cost  of 
domain  engineering  (including  architecture  develop¬ 
ment).  tool  acquisition,  and  integration.  Also,  differ¬ 
ent  testing  and  quality  assurance  processes  often  are 
needed  when  reusing  software.  After  contract  award, 
development  and  maintenance  organizations  should 
establish  monitoring  procedures  that  ensure  the  con¬ 
tractor  is  meeting  the  software  reuse  performance 
standards  described  in  the  statement  of  work. 

High-quality  repositories  may  be  another  upfront 
investment  for  development  and  maintenance  orga¬ 
nizations.  However,  existing  repositories  of  reusable 
software,  such  as  the  DSRS  operated  by  the  SRI 
PMO,  are  available  for  use  by  DOD  components. 

For  organizations  opting  to  develop  and  main¬ 
tain  their  own  repository  for  reusable  software,  auto¬ 
mated  browsing  tools  should  be  acquired  or  devel¬ 
oped  to  facilitate  search  and  retrieval.  Also,  configu¬ 
ration  management  tools  should  be  incorporated  into 
repositories  in  order  to  trace  an  asset  to  the  systems 
in  which  it  was  used. 


There  is  great  pressure  for  early  high-payoff  suc¬ 
cess  stories,  but  the  real  measure  of  success  consid¬ 
ers  the  entire  life-cycle.  Reuse  benefits  are  real  and 
are  documented  in  earlier  sections  of  this  Primer.  Not 
only  will  your  program  benefit  from  software  reuse, 
but  the  benefits  multiply  as  follow-on  programs  take 
advantage  of  your  work.  To  ensure  a  high  payoff 
from  software  reuse: 


The  pressures  for  early  high-payoff  and 
long-term  success  can  divide  and  conquer 
unwary  organizations. 


Invest  in  a  long-term  systematic  software  reuse 
strategy  throughout  the  software  development 
cycle; 

Exploit  high-payoff  ad  hoc  software  reuse  op¬ 
portunities  as  they  occur;  and 

Be  realistic;  do  not  promise  too  much  too  soon. 

What  are  Commok  Mistakes 
AHR  How  Do  I  Ayoid  ThemP 

Plan  and  create  an  infrastructure  to 
avoid  mistakes. 


Allowing  inadequate  configuration  manage¬ 
ment  of  reuse  assets;  which  assets  are  used  in 
which  systems?  Configuration  management 
assists  in  making  the  decision  to  use  a  reusable 
asset  and  in  developing  data  for  estimating  an 
organization’s  return  on  investment.  Establish 
appropriate  configuration  management  mecha¬ 
nisms. 
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•  Inadequately  controlling  what  is  put  in  the 
reuse  library.  Issues  involved  here  are  quality 
of  assets,  breadth  of  functionality,  limiting  rep¬ 
etition.  and  proper  asset  documentation.  Estab¬ 
lish  appropriate  configuration  management 
mechanisms  over  the  library. 

•  Using  inadequate  search/browse/lookup 
mechanisms  in  the  reuse  library.  If  you  can’t 
find  it,  you  can’t  use  it.  Invest  in  support  tools. 


Plan,  create,  and  manage  an  adequate 
infrastructure  of  support  tools  to  avoid 
common  technical  mistakes. 

Incorporating  software  assets  that  are  too 
large  and/or  have  too  many  unanticipated  side 
effects.  Smaller  software  assets  are  better  for 
reuse.  They  have  fewer  unanticipated  side  ef¬ 
fects  and  are  easier  to  categorize.  In  addition, 
they  require  less  overhead  to  maintain. 

Using  reusable  software  that  requires  exces¬ 
sive  overhead  to  compile,  link,  and  execute. 
If  it  is  difficult  to  integrate  an  asset  into  the 
project,  it  won’t  be  used. 

Bypassing  domain  engineering.  Neither  top- 
down  nor  bottom-up  design  is  adequate  to  cap¬ 
ture  the  benefits  of  reuse.  Domain  engineering 
must  be  accomplished.  It  is  often  referred  to  as 
middle-out  design. 

Expecting  a  domain  to  satisfy  all  of  the  re¬ 
quirements  all  of  the  time.  If  the  scope  of  a 
domain  is  too  broad,  then  all  requirements  can¬ 
not  be  captured  and  satisfied  adequately  for  all 
systems  within  the  domain.  Hence,  systems  de¬ 
veloped  from  too  broad  of  a  domain  definition 


will  find  that  requirements,  such  as  performance, 
will  most  likely  suffer. 

Allowing  no  flexibility  for  exceptions  and  over¬ 
rides.  "All  or  nothing"  reuse  does  not  provide 
any  flexibility  to  tailor  reusable  software  to  sat¬ 
isfy  a  new  requirement.  For  software  code,  as 
an  example,  the  result  is  substantial  amounts  of 
"dead  code"  (i.e..  unused  source  code  that  is 
compiled  and  bound  into  the  executable  form). 
This  creates  unnecessary  overhead  and  deters 
reuse. 

Allowing  undocumented  interfaces.  This  re¬ 
sults  in  wasted  time  and  money  as  software  en¬ 
gineers  must  break  into  the  asset’s  "black  box" 
to  determine  its  impact  on  the  project’s  design 
or  its  execution  environment. 

How  Do  I  Measqbe  My 
Retdin  on  Investment? 

•  The  benefits  that  will  best  justify  in¬ 
vesting  in  a  reuse  program  may  be 
organization-unique  (e.g.,  cost,  pro¬ 
ductivity,  quality,  and  reliability) . 

•  Metrics,  algorithms,  and  processes 
should  be  developed  to  measure  re¬ 
turn  on  investment  (ROI). 

•  Historical  and  current  data  must  be 
collected  to  measure  ROI. 


Baseline  measurements  (e.g.,  cost,  productivity, 
reliability,  quality)  must  be  defined  and  the  values 
assigned  for  historical  and  current  projects.  These 
metrics  must  be  chosen  carefully  and  the  algorithms 
used  to  produce  them  should  be  examined  to  deter¬ 
mine  if  they  are  able  to  truly  represent  the  value  of 
reuse.  The  metrics  selected  to  measure  the  benefits 
of  transitioning  to  reuse  should  address  both  process 
(e.g.,  the  depth  and  breadth  of  the  product-line  life- 
cycle)  and  product  (e.g.,  the  number  of  trouble  re¬ 
ports  and  engineering  change  proposals). 

The  measurements  that  will  best  justify  invest¬ 
ment  in  the  reuse  program  may  be  organization- 
unique.  For  example,  reliability  measures,  such  as 
mean  time  between  failures,  mean  time  to  repair  a 
defect,  and  defect  backlog,  would  be  especially  ap¬ 
propriate  for  a  software  maintenance  organization 
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responsible  for  a  weapon  system.  On  the  other  hand, 
a  software  development  organization  would  probably 
be  better  served  by  using  cost  and  productivity  mea¬ 
sures. 

Metrics  should  be  functional  enough  to  be  used 
as  gauges  for  project  success.  They  must  be  eco¬ 
nomical  to  collect  and  report,  and  collection  should 
be  automated.  Mechanisms  should  be  established  to 
accumulate  an  organizational  database  of  historical 
financial  data  relative  to  software  production  and 
maintenance,  including  reuse  activities. 


Plan  for  long-term  investment  in  reuse. 

Treat  technology  transition  as  a  project:  man¬ 
age  it.  resource  it.  schedule  it.  and  measure 
progress. 

Adopt  a  product-line  approach  to  software  ac¬ 
quisition,  development,  and  maintenance. 

Establish  a  systematic  reuse  program. 

Plan,  implement,  and  analyze  incremental  efforts 
to  adopt  reuse. 


The  internalization  of  reuse  principles  into  an  or¬ 
ganization’s  methods  will  evolve  over  time.  Thus, 
the  ROI  seen  at  1 2  months  will  be  less  than  the  ROI 
seen  at  24  or  36  months.  Often,  the  ROI  is  accrued 
on  subsequent  projects. 

Wiur  ABE  My  Next  Steps? 

•  Contact  your  Service  I  Agency  soft¬ 
ware  reuse  POC. 

•  Develop  a  reuse  plan. 

•  Use  the  SRI  PMO  resources. 

•  Provide  leadership  and  resources. 

•  Reward  reuse,  not  alternatives. 

•  Reorganize  to  facilitate  reuse. 

The  next  logical  step  is  to  contact  your  Service/ 
Agency  software  reuse  POC  (Appendix  C),  deter¬ 
mine  if  your  organization  is  ready  for  the  transition, 
and  develop  a  transition  plan  using  the  strategies  dis¬ 
cussed  in  this  Primer.  The  SRI  PMO  also  can  pro¬ 
vide  assistance  and  resources  towards  developing  a 
reuse  plan. 

A  summary  of  management  strategies  to  imple¬ 
ment  and  sustain  software  reuse  within  an  organiza¬ 
tion  follows: 

•  Provide  proactive  leadership  and  resources  at 
the  beginning  of  system  development  projects 
to  encourage  reuse. 

•  Establish  reuse  goals  that  support  achievement 
of  business  and  engineering  objectives. 

•  Provide  a  reward  mechanism  instilling  a  desire 
to  reuse  software  for  development,  maintenance, 
and  acquisition  activities. 


Establish  cost  models  and  program  metrics  to 
facilitate  decisions  on  reuse. 

Provide  comprehensive  and  top-quality  re¬ 
sources  to  development  programmers. 

Establish  organizational  standards  for  design, 
reuse,  and  programming.  Validate  them. 

Enforce  validated  standards  over  whole  devel¬ 
opment  organizations. 

Exploit  ad  hoc  reuse  opportunities  while  con¬ 
currently  building  the  infrastructure  necessary 
to  take  advantage  of  systematic  reuse. 

Seek  mechanisms  for  sharing  reuse  experiences 
and  ideas  (e.g.,  workshops,  conferences,  and 
working  groups). 

Whebe  Do  I  Bo  Fob  Mobe  Infobmatibn? 

•  This  Primer  is  just  the  starting  point. 

•  Contact  the  SRI  PMO  and  Reuse  In¬ 
formation  Clearinghouse  (ReuseIC). 


This  Software  Reuse  Executive  Primer  has  only 
scratched  the  surface.  Further  study  of  the  topics  in 
this  Primer  is  recommended.  The  Bibliography  is  an 
excellent  starting  point.  The  SRI  PMO  and  ReuseIC 
can  provide  information  on  upcoming  conferences  and 
educational  opportunities.  In  addition,  points  of  con¬ 
tact  for  reuse  working  groups  can  be  obtained  from 
these  sources.  Products  developed  by  these  groups 
can  provide  invaluable  help  for  organizations  adopt¬ 
ing  a  software  reuse  program. 


The  ReuseIC  is  the  primary  distribution  mecha-  access  can  be  obtained  by  contacting  Ms.  Susan 
nism  for  reuse  information  operated  by  the  SRI  PMO.  Carlson  at  E-mail:  reuseic@sw-eng.falls- 

The  ReuseIC  provides  public  access  to  reuse  infor-  church.va.us.  Fax:  (703)  68 1  -2869.  and  Voice:  (703 ) 

mation  through  Internet,  a  telephone  hotline,  and  a  681-2464. 
quarterly  newsletter.  Information  about  ReuseIC 


Acrsnyms 


ACM  Association  for  Computing  Machines' 

CARDS  Comprehensive  Approach  to  Reusable  Defense  Software  (formerly  Central  Archive  for  Re¬ 
usable  Defense  Software) 

DISA  Defense  Information  System  Agency 

DOD  Department  of  Defense 

DSRS  Defense  Software  Repository  System 

EUVE  Extreme  Ultraviolet  Explorer 

GAO  Government  Accounting  Office 

IEEE  Institute  of  Electrical  and  Electronics  Engineers,  Inc. 

NIST  National  Institute  of  Standards  and  Technology 

OSD  Office  of  the  Secretary  of  Defense 

PMO  Program  Management  Office 

POC  Point  of  Contact 

RAAT  Reuse  Acquisition  Action  Team 

ReuseIC  Reuse  Information  Clearinghouse 

ReuseWG  Reuse  Working  Group 
ROI  Return  on  Investment 

SAMPEX  Solar,  Anomalous,  and  Magnetospheric  Particle  Explorer 

SIG  Special  Interest  Group 

SPC  Software  Productivity  Center 

SRBM  Software  Reuse  Business  Model 

SRI  Software  Reuse  Initiative 

STARS  Software  Technology  for  Adaptable,  Reliable  Systems 
UARS  Upper  Atmosphere  Research  Satellite 
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